<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <style>
        /*图文环绕*/
        img{
            float: left;
        }
    </style>
</head>
<body>
<img src="../04-选择器的进阶+背景相关属性/img/3.jpg" style="width: 200px" alt="">
【CSDN 编者按】从 2004 年一个人在业余时间默默写下第一行代码，到 2025 年带领一个 50+ 人的全球分布式团队，这位开源项目创始人走过了 21 年的漫长旅程。他的项目不仅获得了超过 3 万颗 GitHub Stars，也在从“兴趣驱动”到“可持续盈利”的转变中，完成了从个人作品到成熟公司的蜕变。在这个过程中，他成立了一家正式公司，与百余位 VC 谈判，历经融资寒冬，坚持理想，也经历现实。在他看来，开源不等于免费劳动，社区也不是营销渠道，而是真正的发动机。

原文链接：https://medium.com/@ben_haynes/i-started-an-open-source-project-in-2004-8d38820a7ecd

作者 | Ben Haynes，Directus 公司 CEO 兼联合创始人     翻译 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

在 2004 年（那时候我还没有孩子，甚至连 GitHub 都还不存在），我开始开发一个小工具，用于我所在创意公司的客户项目。虽然每个项目的需求都不同，但它们有一个共通点——都涉及数据。

当时我经常用 phpMyAdmin，于是脑中突然冒出一个想法：如果我能重写一个更安全、更直观的版本，甚至能放心地交给客户使用，会不会更好？说干就干，我立刻就动手做了。虽然项目初期状况百出且杂乱无章，但它确实能用——只有 PHP、MySQL 和一个我。

没有产品路线图、没有 Discord 社区、也没有什么人气，这个项目就只是我为了满足自己的一个需求罢了。而本周，这个不起眼的副业项目终于突破了 30000 个 GitHub Stars， 如今在 4 亿多个代码库中排名第 772 位。（GitHub 地址：https://github.com/directus/directus）



如果你也好奇一个持续 20 多年的开源项目是什么样子，或者想知道当一个周末做的小玩意儿发展成一家拥有 50 多名员工的公司时会发生什么……那我可以跟你讲讲这一路走来的经历。



0 Star 阶段：从零开始（2004–2014）

我从来没把它当作一个“创业项目”，甚至都没把它叫做一个“项目”：它对我来说，只是一个工具。

整整 10 年，我都在用它处理客户项目，完全没有社区支持，也没有协作者。就我一个人，在不同项目之间靠胶水代码（Glue Code）不断加新功能。那时，除了“把代码放到网上”，我对开源的概念一无所知。我看到了 WordPress 的成功，于是就直接使用了和他们一样的许可证：GPLv3，那是 2011 年的事。

之后，我在桌子上放了个小型硬件计数器，能实时显示 GitHub Star 数。每多一个 Star，我都觉得激动万分，就好像有人在某个地方发现了这个项目。那种感觉很特别，一点一滴的成就感，非常真实。

后来，我妈开始频繁问我问题，主要意思就是：“你为什么花那么多时间做一个免费的东西？”当时，我也没法给出一个很好的答案………… 但我知道，只要它真的受欢迎，其他问题自然会迎刃而解。

在这个阶段，我得到的经验是：记得要为自己而开发，不要盲目跟风。如果它不能解决你自己的问题，那它也无法解决其他人的问题。



1 万 Stars 阶段：发展势头来了（2015–2020）

突然之间……人们开始注意到它了，而我甚至都不知道它是怎么火起来的。Reddit 帖子？GitHub Explore 推荐？还是有开发者在 Slack 群里分享？

一切都令人兴奋，同时也变得混乱。

在那种混乱的局面中，我开始不再仅仅把这个软件当作一个副业项目了。虽然我偶尔还会接一些客户的单子来维持生计，但大部分时间都投入到这个项目里了。

也就是在那个时候，我遇到了 Rijk van Zanten——就是后来成为我联合创始人的那位。我们一起对我那杂乱无章的代码进行了整理，让它变得更加稳定。技术栈也做了重大迁移：从 Backbone 框架迁移到了 Vue 框架，从 PHP 语言迁移到了 Node 语言。这次重构是一个转折点。

有一次，我们被邀请飞到旧金山，向一家价值数十亿美元的网约车公司推销这个软件。他们告诉我，这是他们评估过的最好的解决方案——但他们不可能把整个数据体系压在一个“两人作坊”的项目上。嗯……这话倒也没错。

随后，各种 issue、PR 和功能请求开始纷至沓来。其中有些确实很有价值，但处理起来也非常耗时。而且，想从各种杂乱的信息中找到真正有用的内容变得越来越难。很多 PR 都是为了解决某个特定用户自己的问题，缺乏通用性。但我们明白，如果要让项目长期可持续，就必须跳出眼前的小需求，把这些具体问题抽象为普适性的解决方案。

这是一种思维方式的转变，也是一件非常耗神的事。

在这个阶段，我得到的经验是：简单的东西才能扩展，但技术债也会随之增加。学会说“不”，比只会说“好”更重要。
</body>
</html>